Payments in Communication Systems

ABSTRACT

Users of a communication system can initiate electronic payments during a communication session hosted by the communication system or via a social network identity page hosted by the communication system. The communication system detects a payment signal from a user of the communication system and the collects payment information details either by displaying a payment object interface in a communication application of the user or receiving payment information input directly from the user&#39;s communication device. The payment information includes sender and recipient payment account identifiers that are communicated to a payment processing system for processing and delivery of the designated payment amount to the recipient.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/801,277 filed Mar. 15, 2013 and entitled “Payments inCommunication Systems.” The entire contents of the above-identifiedapplication are hereby fully incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to systems and methods for conductingelectronic peer-to-peer payments. More particularly, the presentdisclosure provides systems and methods for initiating and completingelectronic payments using synchronous communication systems.

BACKGROUND

When communicating using synchronous communication systems, such asinstant messaging and videoconference, users often discuss detailsrelated to payments, including money owed to one another. Ideally, sucha discussion during a synchronous communication session would not beinterrupted in order to complete a payment. In conventionalcommunication systems, payments can be made only by interrupting theconversation to open a separate browser window to access a paymentservice and then optionally to use a screen-sharing function to confirmthat payment details are correct. Each of these actions interrupts theconversation and moves the focus away from the discussion at hand.Likewise, users are often reminded of money they owe to otherindividuals when reviewing their own social networking news feeds orviewing the social network identity pages of their contacts within theirsocial network. Currently, a way to initiate an electronic paymentduring a synchronous communication session or directly from anotherusers social network identity page does not exist.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a system for sending electronicpayments via communication systems, in accordance with certain exampleembodiments.

FIG. 2 is a block flow diagram depicting a method to send electronicpayments via communication systems, in accordance with certain exampleembodiments.

FIG. 3 is a block flow diagram depicting a method to collect paymenttransaction information from the sender, in accordance with certainexample embodiments.

FIG. 4 is a block flow diagram depicting a method to send electronicpayments via communication systems, in accordance with certain exampleembodiments.

FIG. 5 is a block flow diagram depicting a method to collect paymenttransaction information from the sender, in accordance with certainexample embodiments.

FIG. 6 is a block diagram depicting a computing machine and a module, inaccordance with certain example embodiments.

SUMMARY

In certain example embodiments described herein, a method to sendelectronic payments via communication systems comprises initiating acommunication session between two remote computing devices over asynchronous communication network, detecting a payment option signalfrom one of the remote computing devices indicating the intent of a userto send an electronic payment to another user participating in thecommunication session, displaying a payment information object in acommunication application of the user sending the payment, receivingpayment information entered by the sender at the payment informationobject, and communicating the received payment information to a paymentprocessing system for processing of the payment and delivery of thepayment amount to a payment account of the recipient.

In certain other example embodiments described herein, a method to sendelectronic payments via a recipient's social network identity pagecomprises detecting selection by a user of a payment object interfacedisplayed on a recipient's social network identity page, displaying apayment information object interface to the user on the recipient'ssocial network identity page, receiving payment information from theuser entered at the payment object interface, and communicating thereceived payment information to a payment processing system forprocessing of the payment and delivery of the payment amount to apayment account of the recipient.

These and other aspects, objects, features, and advantages of theexample embodiments will become apparent to those having ordinary skillin the art upon consideration of the following detailed description ofillustrated example embodiments.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

The methods and systems described herein enable users to make paymentsover an internet communication network. Example internet communicationsystems include audio conferencing systems, video conferencing systems,voice over internet protocol (VOIP) systems, instant messaging systems,social network system, and various synchronous communication systems. Incertain example embodiments, an internet communication system mayinclude a combination of VOIP, audio conferencing, video conferencing,instant messaging, and social network communications. In certain exampleembodiments, internet communication systems do not include e-mailsystems. The embodiments described herein provide a user interface thatallows a sender to initiate a payment directly from a communicationapplication executing on a remote client computing device while engagingin a communication session on one or more of the above internetcommunication systems. In some embodiments, a payment applicationprogram interface library (API) allows the payment system of the presentdisclosure to communicate with sender and recipient applications duringa communication session, detect a payment signal from the senderrecipient communication application, and display a payment object in thesender communication application to collect payment transactioninformation from the sender. In some embodiments, the techniquesdescribed herein are integrated with the communication applications. Invarious embodiments of the techniques described herein, users may needto install a particular application and/or add-on module, and/or selecta service for operation in order to obtain the benefits of thetechniques described herein.

In one example embodiment, a sender initiates a payment over an internetcommunication system by selecting a payment option user interfacedisplayed in the sender communication application. In certain otherexample embodiments, the sender may signal their intent to initiate apayment through one or more textual, audio, or visual signals. Forexample, a payment signal may comprise typing a textual signal such as a“$” or “I owe you” in a text-based communication, or through an audiocommand such as “send payment.” In certain example embodiments, thepayment signal may comprise obtaining an image capture of a currencybank note, such as a United States five-dollar bill. The system detectsthe payment signal and loads a payment object for display in the sendercommunication application. The payment object comprises a set of fieldsfor collecting payment details from the sender. The sender enters thepayment details in the payment object. In certain example embodiments,the recipient of the payment is automatically determined based on withwhom the sender is communicating in a current communication session. Incertain example embodiments, the payment amount is automaticallydetermined by the image capture of a currency banknote, where the valueof the currency banknote equals the payment amount.

The payment transaction details collected by the payment object arecommunicated by the API to the payment system. The payment systemcommunicates the payment transaction details to a payment processingsystem. In certain example embodiments, the payment processing systemmay be an electronic wallet system, and the sender and recipientidentifiers are the sender and recipient electronic wallet accountidentifiers. In certain example embodiments, the payment system mayfirst request verification from the payment processing system thatsufficient funds are available in the sender's payment account. Ifsufficient funds are not available, the payment system will display anotification to the sender in the sender communication application andprovide the sender an option to modify their electronic accountsettings. For example, a sender may be able to select a differentpayment instrument, such as a different credit card, to continueprocessing the payment, or the sender may transfer additional funds intotheir electronic payment account. In certain other example embodiments,the payment system may display a security challenge in the sendercommunication application, requesting verification of the sender'sidentity before proceeding with the payment transaction. In certainother example embodiments, the payment system may display a paymentnotification object in each recipient communication application. Thenotification may request an acceptance notification from the recipientbefore proceeding with processing of the payment. Once the paymenttransaction information is accepted, the payment processing systemtransfers the indicated payment amount from the sender electronicpayment account to the recipient payment account. The payment systemthen displays a payment confirmation in the sender and recipientcommunication applications or sends a confirmation to the sender andrecipient through a separate communication channel, such as e-mail ortext message. The payment system may also log a transaction summary ofthe payment transaction in a payment log or communication log of theinternet communication system.

In another example aspect, a sender initiates a payment transactionwhile accessing a social network. The sender may initiate a payment whenaccessing a recipient identity page by selecting a payment object linkdisplayed on the recipient identity page. A payment object is displayed,payment transaction information is collected, and processing of thepayment proceeds substantially as described in the example embodimentabove. Likewise, the recipient may receive a payment notification and begiven the option to accept or decline the payment. In certain exampleembodiments, a payment confirmation is posted on the recipient identitypage, the sender identity page, or both.

Turning now to the drawings, in which like numerals represent like (butnot necessarily identical) elements throughout the figures, exampleembodiments are described in detail more detail.

Example System Architectures

FIG. 1 is a block diagram depicting a system for sending electronicpayments via communication systems, in accordance with certain exampleembodiments. As depicted in FIG. 1, the system 100 includes networkdevices 105, 110, 120, and 130 that are configured to communicate withone another via one or more networks 115.

Each network 115 includes a wired or wireless telecommunication means bywhich network devices (including devices 105, 110, 120, and 130) canexchange data. For example, each network 115 can include a local areanetwork (“LAN”), a wide area network (“WAN”), an intranet, an Internet,a mobile telephone network, or any combination thereof. Throughout thediscussion of example embodiments, it should be understood that theterms “data” and “information” are used interchangeably herein to referto text, images, audio, video, or any other form of information that canexist in a computer-based environment.

Each network device 105, 110, 120, and 130 includes a device having acommunication application 106 and 111 capable of transmitting andreceiving data over the network 115. For example, each network device105, 110, 120, and 130 can include a server, desktop computer, laptopcomputer, tablet computer, a television with one or more processorsembedded therein and/or coupled thereto, smart phone, handheld computer,personal digital assistant (“PDA”), or any other wired or wireless,processor-driven device. In the example embodiment depicted in FIG. 1,the network devices 105, 110 are operated by end-users or consumers (notdepicted). The network devices 120, 130 are operated by communicationsystem operators (not depicted) and payment processing operators (notdepicted), respectively.

An end-user can use a communication application 106 and 111, such as aweb browser application or a stand-alone application, to view, download,upload, or otherwise access documents or web pages via a distributednetwork 115. The network 115 includes a wired or wirelesstelecommunication system or device by which network devices (includingdevices 110, 135 and 140) can exchange data. The communicationapplications 106 and 111 can interact with web servers or othercomputing devices connected to the network 115, including communicationsystem 120 and payment processing system 130.

It will be appreciated that the network connections shown are by way ofexample and other means of establishing a communications link betweenthe computers and devices can be used. Moreover, those having ordinaryskill in the art and having the benefit of the present disclosure willappreciate that the sender and recipient remote computing devices 105,110, communication system 120, and payment processing system 130illustrated in FIG. 1 can have any of several other suitable computersystem configurations. For example, a sender remote computing device 105embodied as a mobile phone or handheld computer may not include all thecomponents described above and/or may include other components.

Example Processes

The components of the example operating environment 100 are described inmore detail hereinafter with reference to the example methodsillustrated in FIGS. 2-5. The example methods of FIGS. 2-5 may also beperformed with other systems and in other environments.

FIG. 2 is a block flow diagram depicting a method 200 to send electronicpayments via communication systems, in accordance with certain exampleembodiments.

Method 200 begins with block 205, where a sender remote computing device105 initiates a synchronous communication session with one or morerecipient remote computing devices 110 via the communication system 120.In some embodiments, the user associated with a particular device mustinstall an application and/or make a feature selection to obtain thebenefits of the techniques described herein.

A synchronous communication session enables same time communication andcollaboration between different remote computing devices in differentgeographical locations. Example synchronous communication sessionsinclude, but are not limited to, audio conferencing, web conferencing,video conferencing, chat rooms, instant messaging, and application orscreen sharing. In certain example embodiments, a synchronouscommunication session conducted via the communication system 120 mayinvolve two or more of the above types of synchronous communication. Forexample, a video conferencing session may be a web-based conferencingsession that also includes application or screen sharing functions. Acommunication channel is established between the sender and recipientremote computing devices 105, 110 via the communication network server122 of the communication system 120.

At block 210, the payment module 124 detects a payment signal reflectinga sender's intent to send a payment via the communication system 120during a synchronous communication session, the sender being associatedwith a sender remote computing device 105. The payment module 124 maydetect the sender's intent via the sender's interaction with a paymentobject displayed in the communication application 106, or by detectionof a text-based payment signal, an audio-based payment signal, or animage-based detection signal.

Regarding payment signals detected from a sender's interaction with auser interface displayed in the communication application 106, a paymentAPI library 126 may be installed on the sender and recipient remotecomputing devices 105, 110. The payment API library 126 comprisescomputer-executable code instructions that allows the communicationapplication 106 on the sender and recipient remote computing devices 105and 110 to communicate with the payment module 124 on the communicationsystem 120. When a synchronous communication session is initiated usingthe communication application 106 on the sender remote computing device105, a payment object is displayed to the sender by the communicationapplication 106. The payment API library 126 allows a payment interfaceobject, such as a button, to be displayed in the user interface of thecommunication application 106. When the sender selects the paymentinterface object, the payment API library 126 communicates the selectionto the payment module 124.

Regarding detection of audio and text-based payment signals, the paymentmodule 124 may monitor the communication session directly for suchpayment signals. For example, the payment module 124 may monitor anaudio-based communication session for the verbal command “send payment.”Alternatively, the payment module 124 may monitor the communication fora text-based payment signal such as “$” or “send payment.” Accordingly,in such embodiments detection of the payment signal may not requiredetection by an API library executing on the sender remote computingdevice 105. In certain example embodiments, the audio and text-basedpayment signal monitoring of communication sessions may be disabled bythe users of the communication session 120.

Regarding detection of an imaged-based payment signal, the paymentmodule 124 may monitor the communication session directly for theimage-based payment signal. For example, the payment monitor module 124may monitor the communication session for transmission of an image of acurrency banknote, such as a United States dollar bill. In certainexample embodiments, the user may first select a payment objectinterface as described above and then be provided with the option totake a picture using a camera associated with the sender remotecomputing device 105 of a currency banknote to designate the paymentamount they wish to send. The payment API library 126 recognizes thecurrency value based on the captured image and will communicate thecurrency value to the payment module 124.

At block 215, the payment module 124 collects sender paymentinformation. Block 215 is described in further detail hereinafter withreference to FIG. 3.

FIG. 3 is a block for diagram depicting a method 215 for collectingsender payment information, in accordance with certain exampleembodiments. The method 215 is described with reference to thecomponents illustrated in FIG. 1.

Method 215 begins at block 305, where the payment module 124 requestpayment transaction details from the sender. Payment transaction detailsinclude at least a sender payment account identifier, one or morerecipient identifiers, and a payment amount. In certain exampleembodiments, all other participants in the communication session aredesignated as recipients. Where the image-based payment signal is animage capture of a currency banknote, the payment amount isautomatically set to the value of the currency banknote. In certainexample embodiments, the payment module 124 may collect the paymenttransaction details by communicating a series of audio prompts to thesender remote computing device 105 and recording the sender's responseusing standard voice recognition methods or by receiving data input bythe sender using a hard keypad on the remote computing device 105 or asoft keypad displayed within the communication application 106. In otherexample embodiments, a payment information object interface is displayedin the communication application 106 via the payment API library 126.The payment information object comprises fields where the sender mayenter the requested payment information, or modify pre-populated fieldssuch as designated recipients and payment amount.

At block 310 the payment module 124 receives the payment transactiondetails from the sender remote computing device 105. If the synchronouscommunication comprises an audio component and the payment transactionsdetails are collected by audible responses to audio prompts from thepayment module 124, the payment module 124 may establish a separatecommunication session and mute the primary communication session so thesender may privately provide payment information.

At block 315, the payment module 124 determines if the sender hasindicated multiple recipients for the payment based on informationentered in the payment information received in reference to block 305above. If there are multiple recipients, the method proceeds to block320.

At block 320, the payment module 124 confirms a payment amount has beendesignated for each recipient. For example, the payment module 124 maypresent a multi-recipient payment detail object via the communicationapplication 106 to the sender listing each recipient and providing afield to indicate the payment amount for each recipient. In certainexample embodiments, the payment module 124 may list the same paymentamount for each recipient in the multi-recipient modal by default. Thesender, may then edit the payment amounts and add or remove recipientsas needed in the multi-recipient payment details object and communicatethose edits to the payment module 124 by selecting a submituser-interface object displayed on the multi-recipient payment detailsobject. The method then proceeds to block 325.

Returning to block 315, if the payment module 124 determines there isonly a single recipient, the method proceeds directly to block 325.

At block 325, the payment module 124 communicates the payment details tothe payment processing system 130 and requests a payment account status.The payment processing system 130 comprises an account index 132. Theaccount index 132 comprises sender 134 and recipient 136 paymentaccounts (or records) associated with information such as user accountidentifier and payment account information, such as credit card accountinformation.

Where the payment information object indicates multiple paymentrecipients, the payment module 124 may communicate payment details tothe payment processing system 130 for each recipient separately. Thepayment processing system 130 uses the sender payment account identifierto access the sender payment account 134 and verify there are sufficientfunds associated with the selected payment instrument for each requestedpayment. If the payment account status response from the paymentprocessing system 130 indicates there are not sufficient funds to coverthe payment amount indicated in the payment details the method proceedsto block 330.

At block 330, the payment module 124 displays a modify account object tothe sender through the communication application 106 or provides aseries of audio prompts regarding the need to update or modify thesender's payment account information. For example, the payment module124 may display a modify account object interface that indicates thedeficiency of funds and presents the sender with the option of modifyingthe payment details or canceling the payment transaction. If the senderelects to modify the account, the method returns to block 315 and steps315 to 325 are repeated. The sender may modify the sender paymentaccount 134, for example, by selecting a different payment instrument,or accessing the sender payment account 134 and authorizing the transferof additional funds into the payment account, or by updating paymentinformation associated with the sender payment account 134. If thesender elects to cancel the payment transaction, the method terminates.The communication session may continue as needed.

Returning to block 325, if the payment module 124 receives confirmationfrom the payment processing system 130 that there are sufficient fundsavailable the method proceeds directly to block 335.

At block 335, the payment module 124 determines if a security challengeis needed before allowing the payment transaction to be completed. Forexample, the payment module 124 may determine if a security challenge isneeded based on the payment amount, the amount of payment instrumentinformation stored in the sender payment account 134, whether thepayment is being made to someone within the sender's social network, ora combination thereof. The security challenge may require new paymentaccount information such as full billing address, or the confirmation ofknown details such as the credit card number of the selected paymentinstrument. In certain other example embodiments, the security challengemay also require the sender to prove they are in possession of avalidation code. For example, the payment module 124 may send a textmessage containing a validation code to a cell phone number associatedwith the sender's payment account. If the payment module 124 determinesa security challenge is required the process proceeds to block 340.

At block 340, the payment module 124 displays a security challengeobject to the sender via the communication application 106, or providesa security challenge audio prompt, and determines if the securitychallenge has been passed based on the information received from thesender. If the security challenge is passed the method proceeds to block220 of FIG. 2. If the security challenge fails, the method terminates.In certain example embodiments, the sender may be given a limited numberof additional attempts to provide the correct security challengeverification information before the payment process terminates. If thepayment process terminates, the communication session may continue asneeded.

Returning to block 335, if the payment module 124 determines a securitychallenge is not required the method proceeds directly to block 220 ofFIG. 2. The payment module 124 may determine a security challenge is notrequired based on factors such as, the payment amount, the length oftime from the last login or use of the system, or the amount of accountinformation stored in the sender's payment account.

Returning to FIG. 2 at block 220, where the payment module 124communicates a final payment request comprising the payment transactiondetails to the payment processing system 130. In certain exampleembodiments, the payment module 124 may first communicate an acceptancenotification to the recipient or recipient remote computing device 110,the communication notification including an option to accept or rejectthe payment, before communicating the final payment request to thepayment processing system 130. If the payment module 124 receives anacceptance notification from the recipient remote computing device 110,the payment module 124 communicates the final payment request to thepayment processing device 124. If the payment module 124 receives arejection notification from the recipient remote computing device 110,then the payment process terminates. The communication session maycontinue as needed. In certain example embodiments, if multiplerecipients are designated and only a portion of the recipients acceptthe payment, the payment module 124 will first update the final paymentrequest to remove the payment transaction details relating to therecipients that declined the payment before communicating the finalpayment request to the payment processing system 130.

At block 225, the payment processing system 130 processes the paymentrequest. The payment processing system 130 accesses the sender paymentaccount 134 based on the sender payment account identifier included inthe payment request. If a recipient payment account 136 identifier wasincluded in the payment request the payment processing system 130 usesthat identifier to access the recipient payment account(s) 136. If arecipient payment account identifier was not included, or the recipientdoes not have a payment account registered with the payment processingsystem 130, the payment processing system 130 may communicate aregistration request to the recipient. The registration request may besent directly to the recipient, for example, by email if an emailaddress for the recipient was included in the payment request, orthrough any other suitable mode of communication. Alternatively, thepayment processing system 130 may communicate the registration requestto the payment module 124. The payment module 124 will then display aregistration request object in the recipient communication application111 or provide a series of audio prompts directing the recipient on howto register for a payment account with the payment processing system130. Once the payment processing payment system 130 has both a senderand recipient payment account identifier, the payment processing system130 processes the payment and transfers the designated payment amountfrom the sender payment account 134 to the recipient payment account136.

At block 230, the payment module 124 receives a payment confirmationfrom the payment processing system 130 that the payment has beencompleted.

At block 235, the payment module 124 may record a payment transactionrecord in a payment transaction logged stored in the communicationsystem 120. The payment transaction log may be accessed by users of thecommunication system 120 to reference previous payments made duringprevious communication sessions. The payment module 124 may assign atransaction identifier to each record to facilitate searching pasttransactions, or may identify past transaction in the transaction log bysender or recipient identifier.

At block 240, the payment module 124 communicates a payment confirmationto the recipient and sender. The payment module 124 may display aconfirmation object in the communication applications 106 and 111 of therecipient and sender respectively, or may communicate the paymentconfirmation via a separate communication mode, such as by text messageor email to the sender and recipient.

FIG. 4 is a block flow diagram depicting a method 400 to send electronicpayments via social networking identity pages, in accordance withcertain alternative example embodiments.

Method 400 begins with block 405 where a sender communicationapplication 106 displays a recipient social networking identity pagewhen a sender associated with the sender communication application 106accesses the recipient's identity page. A social networking identitypage is associated with a recipient's social network account stored in auser account index 128. The payment API library 126 displays a paymentobject interface on the recipient's social networking page. In certainexample embodiments, the payment API 126 may first reference therecipient's social networking account to determine if the recipient hasenabled social networking payments and has registered the necessaryelectronic payment account information, such as a payment accountidentifier, before displaying the payment object interface on therecipient's identity page. In certain example embodiments, the paymentAPI 126 may display a request payment access object that allows a senderto notify the recipient they wish to be able to send electronic paymentsfrom the recipient's identity page. Upon selection of this requestpayment access object, the payment API library 126 will notify therecipient and prompt them to enable social networking payments andregister for, or provide existing electronic payment accountinformation.

At block 410, the payment API library 126 communicates a notification tothe payment module 124 in response to a sender selecting the paymentobject interface displayed on the recipient's identity page therebyindicating the sender's intent to send a payment via the communicationsystem 120.

At block 415, the payment module 124 collects the sender's paymenttransaction details. The method 415 is described in further detailhereinafter with reference to FIG. 5.

FIG. 5 is a block diagram depicting a method 415 for collecting senderpayment transaction details, in accordance with certain exampleembodiments. The method 210 is described with reference to thecomponents illustrated in FIG. 1.

Method 415 begins at block 505. Blocks 505 and 510 proceed substantiallyas described above regarding blocks 305 and 310 of FIG. 3, and blocks515 to 530 proceed substantially as described above regarding blocks 325to 340 of FIG. 3.

Returning to FIG. 4 at block 420, where the payment module 124communicates the payment transaction details to the payment processingsystem 130. Blocks 420 through 430 then proceed substantially asdescribed above regarding blocks 220 and 230 and FIG. 2. In certainexample embodiments, the payment module 124 may communicate a record ofthe payment via the payment API library 126 for display on the identitypage of the sender, recipient, or both. The record may indicate onlythat a payment was made or provide more information such as paymentamount and a memo on what the payment was for.

In certain example embodiments, a user may request a payment, as well assend a payment. A user initiates a request by selecting the paymentobject on the requested identity page and indicating at least therequested amount. A payment request notification may be sent to therequestee indicating the requestor's identity and the requested paymentamount. If the requestee accepts the payment request, the requesteebecomes the sender and the requestor becomes the recipient, and thepayment process proceeds as described above regarding blocks 405 to 430above.

Other Example Embodiments

FIG. 6 depicts a computing machine 2000 and a module 2050 in accordancewith certain example embodiments. The computing machine 2000 maycorrespond to any of the various computers, servers, mobile devices,embedded systems, or computing systems presented herein. The module 2050may comprise one or more hardware or software elements configured tofacilitate the computing machine 2000 in performing the various methodsand processing functions presented herein. The computing machine 2000may include various internal or attached components such as a processor2010, system bus 2020, system memory 2030, storage media 2040,input/output interface 2060, and a network interface 2070 forcommunicating with a network 2080.

The computing machine 2000 may be implemented as a conventional computersystem, an embedded controller, a laptop, a server, a mobile device, asmartphone, a set-top box, a kiosk, a vehicular information system, onemore processors associated with a television, a customized machine, anyother hardware platform, or any combination or multiplicity thereof. Thecomputing machine 2000 may be a distributed system configured tofunction using multiple computing machines interconnected via a datanetwork or bus sy stem.

The processor 2010 may be configured to execute code or instructions toperform the operations and functionality described herein, managerequest flow and address mappings, and to perform calculations andgenerate commands. The processor 2010 may be configured to monitor andcontrol the operation of the components in the computing machine 2000.The processor 2010 may be a general purpose processor, a processor core,a multiprocessor, a reconfigurable processor, a microcontroller, adigital signal processor (“DSP”), an application specific integratedcircuit (“ASIC”), a graphics processing unit (“GPU”), a fieldprogrammable gate array (“FPGA”), a programmable logic device (“PLD”), acontroller, a state machine, gated logic, discrete hardware components,any other processing unit, or any combination or multiplicity thereof.The processor 2010 may be a single processing unit, multiple processingunits, a single processing core, multiple processing cores, specialpurpose processing cores, co-processors, or any combination thereof.According to certain embodiments, the processor 2010 along with othercomponents of the computing machine 2000 may be a virtualized computingmachine executing within one or more other computing machines.

The system memory 2030 may include non-volatile memories such asread-only memory (“ROM”), programmable read-only memory (“PROM”),erasable programmable read-only memory (“EPROM”), flash memory, or anyother device capable of storing program instructions or data with orwithout applied power. The system memory 2030 may also include volatilememories such as random access memory (“RAM”), static random accessmemory (“SRAM”), dynamic random access memory (“DRAM”), and synchronousdynamic random access memory (“SDRAM”). Other types of RAM also may beused to implement the system memory 2030. The system memory 2030 may beimplemented using a single memory module or multiple memory modules.While the system memory 2030 is depicted as being part of the computingmachine 2000, one skilled in the art will recognize that the systemmemory 2030 may be separate from the computing machine 2000 withoutdeparting from the scope of the subject technology. It should also beappreciated that the system memory 2030 may include, or operate inconjunction with, a non-volatile storage device such as the storagemedia 2040.

The storage media 2040 may include a hard disk, a floppy disk, a compactdisc read only memory (“CD-ROM”), a digital versatile disc (“DVD”), aBlu-ray disc, a magnetic tape, a flash memory, other non-volatile memorydevice, a solid state drive (“SSD”), any magnetic storage device, anyoptical storage device, any electrical storage device, any semiconductorstorage device, any physical-based storage device, any other datastorage device, or any combination or multiplicity thereof. The storagemedia 2040 may store one or more operating systems, application programsand program modules such as module 2050, data, or any other information.The storage media 2040 may be part of, or connected to, the computingmachine 2000. The storage media 2040 may also be part of one or moreother computing machines that are in communication with the computingmachine 2000 such as servers, database servers, cloud storage, networkattached storage, and so forth.

The module 2050 may comprise one or more hardware or software elementsconfigured to facilitate the computing machine 2000 with performing thevarious methods and processing functions presented herein. The module2050 may include one or more sequences of instructions stored assoftware or firmware in association with the system memory 2030, thestorage media 2040, or both. The storage media 2040 may thereforerepresent examples of machine or computer readable media on whichinstructions or code may be stored for execution by the processor 2010.Machine or computer readable media may generally refer to any medium ormedia used to provide instructions to the processor 2010. Such machineor computer readable media associated with the module 2050 may comprisea computer software product. It should be appreciated that a computersoftware product comprising the module 2050 may also be associated withone or more processes or methods for delivering the module 2050 to thecomputing machine 2000 via the network 2080, any signal-bearing medium,or any other communication or delivery technology. The module 2050 mayalso comprise hardware circuits or information for configuring hardwarecircuits such as microcode or configuration information for an FPGA orother PLD.

The input/output (“I/O”) interface 2060 may be configured to couple toone or more external devices, to receive data from the one or moreexternal devices, and to send data to the one or more external devices.Such external devices along with the various internal devices may alsobe known as peripheral devices. The I/O interface 2060 may include bothelectrical and physical connections for operably coupling the variousperipheral devices to the computing machine 2000 or the processor 2010.The I/O interface 2060 may be configured to communicate data, addresses,and control signals between the peripheral devices, the computingmachine 2000, or the processor 2010. The I/O interface 2060 may beconfigured to implement any standard interface, such as small computersystem interface (“SCSI”), serial-attached SCSI (“SAS”), fiber channel,peripheral component interconnect (“PCP”), PCI express (PCIe), serialbus, parallel bus, advanced technology attached (“ATA”), serial ATA(“SATA”), universal serial bus (“USB”), Thunderbolt, FireWire, variousvideo buses, and the like. The I/O interface 2060 may be configured toimplement only one interface or bus technology. Alternatively, the I/Ointerface 2060 may be configured to implement multiple interfaces or bustechnologies. The I/O interface 2060 may be configured as part of, allof, or to operate in conjunction with, the system bus 2020. The I/Ointerface 2060 may include one or more buffers for bufferingtransmissions between one or more external devices, internal devices,the computing machine 2000, or the processor 2010.

The I/O interface 2060 may couple the computing machine 2000 to variousinput devices including mice, touch-screens, scanners, biometricreaders, electronic digitizers, sensors, receivers, touchpads,trackballs, cameras, microphones, keyboards, any other pointing devices,or any combinations thereof. The I/O interface 2060 may couple thecomputing machine 2000 to various output devices including videodisplays, speakers, printers, projectors, tactile feedback devices,automation control, robotic components, actuators, motors, fans,solenoids, valves, pumps, transmitters, signal emitters, lights, and soforth.

The computing machine 2000 may operate in a networked environment usinglogical connections through the network interface 2070 to one or moreother systems or computing machines across the network 2080. The network2080 may include wide area networks (WAN), local area networks (LAN),intranets, the Internet, wireless access networks, wired networks,mobile networks, telephone networks, optical networks, or combinationsthereof. The network 2080 may be packet switched, circuit switched, ofany topology, and may use any communication protocol. Communicationlinks within the network 2080 may involve various digital or an analogcommunication media such as fiber optic cables, free-space optics,waveguides, electrical conductors, wireless links, antennas,radio-frequency communications, and so forth.

The processor 2010 may be connected to the other elements of thecomputing machine 2000 or the various peripherals discussed hereinthrough the system bus 2020. It should be appreciated that the systembus 2020 may be within the processor 2010, outside the processor 2010,or both. According to some embodiments, any of the processor 2010, theother elements of the computing machine 2000, or the various peripheralsdiscussed herein may be integrated into a single device such as a systemon chip (“SOC”), system on package (“SOP”), or ASIC device.

In situations in which the systems discussed here collect personalinformation about users, or may make use of personal information, theusers may be provided with a opportunity to control whether programs orfeatures collect user information (e.g., information about a user'ssocial network, social actions or activities, profession, a user'spreferences, or a user's current location), or to control whether and/orhow to receive content from the content server that may be more relevantto the user. In addition, certain data may be treated in one or moreways before it is stored or used, so that personally identifiableinformation is removed. For example, a user's identity may be treated sothat no personally identifiable information can be determined for theuser, or a user's geographic location may be generalized where locationinformation is obtained (such as to a city, ZIP code, or state level),so that a particular location of a user cannot be determined. Thus, theuser may have control over how information is collected about the userand used by a content server.

Embodiments may comprise a computer program that embodies the functionsdescribed and illustrated herein, wherein the computer program isimplemented in a computer system that comprises instructions stored in amachine-readable medium and a processor that executes the instructions.However, it should be apparent that there could be many different waysof implementing embodiments in computer programming, and the embodimentsshould not be construed as limited to any one set of computer programinstructions. Further, a skilled programmer would be able to write sucha computer program to implement an embodiment of the disclosedembodiments based on the appended flow charts and associated descriptionin the application text. Therefore, disclosure of a particular set ofprogram code instructions is not considered necessary for an adequateunderstanding of how to make and use embodiments. Further, those skilledin the art will appreciate that one or more aspects of embodimentsdescribed herein may be performed by hardware, software, or acombination thereof, as may be embodied in one or more computingsystems. Moreover, any reference to an act being performed by a computershould not be construed as being performed by a single computer as morethan one computer may perform the act.

The example embodiments described herein can be used with computerhardware and software that perform the methods and processing functionsdescribed previously. The systems, methods, and procedures describedherein can be embodied in a programmable computer, computer-executablesoftware, or digital circuitry. The software can be stored oncomputer-readable media. For example, computer-readable media caninclude a floppy disk, RAM, ROM, hard disk, removable media, flashmemory, memory stick, optical media, magneto-optical media, CD-ROM, etc.Digital circuitry can include integrated circuits, gate arrays, buildingblock logic, field programmable gate arrays (FPGA), etc.

The example systems, methods, and acts described in the embodimentspresented previously are illustrative, and, in alternative embodiments,certain acts can be performed in a different order, in parallel with oneanother, omitted entirely, and/or combined between different exampleembodiments, and/or certain additional acts can be performed, withoutdeparting from the scope and spirit of various embodiments. Accordingly,such alternative embodiments are included in the inventions describedherein.

Although specific embodiments have been described above in detail, thedescription is merely for purposes of illustration. It should beappreciated, therefore, that many aspects described above are notintended as required or essential elements unless explicitly statedotherwise. Modifications of, and equivalent components or actscorresponding to, the disclosed aspects of the example embodiments, inaddition to those described above, can be made by a person of ordinaryskill in the art, having the benefit of the present disclosure, withoutdeparting from the spirit and scope of embodiments defined in thefollowing claims, the scope of which is to be accorded the broadestinterpretation so as to encompass such modifications and equivalentstructures.

1-22. (canceled)
 23. A computer-implemented method to facilitate, by oneor more computing devices, electronic payments via social networkingsystems, comprising: providing for display, a recipient social networkidentity page in a social networking application on a sender remotecomputing device, the recipient social network identity page including apayment object interface; detecting selection of the payment objectinterface indicating that a user associated with the sender remotecomputing device intends to send a payment to a recipient associatedwith the recipient social network identity page; in response to thedetecting, providing for display, a payment information object on thedisplayed recipient social network identity page, the paymentinformation object enabling receipt of payment transaction informationby the one or more computing devices via the sender remote computingdevice; receiving the payment transaction information from the senderremote computing device; and communicating to a payment processingsystem the received payment transaction information and an instructionto settle a payment amount from a sender payment account associated withthe user to a recipient payment account associated with the recipient.24. The computer-implemented method of claim 23, wherein: the paymentobject interface includes one or more fields to receive an input of thepayment transaction information.
 25. The computer-implemented method ofclaim 24, wherein: the one or more fields are pre-populated with atleast a portion of the payment transaction information.
 26. Thecomputer-implemented method of claim 23, wherein: the paymenttransaction information comprises at least a sender payment accountidentifier associated with a sender payment account and the paymentamount
 27. The computer-implemented method of claim 23 wherein thepayment amount is determined by an image capture of a currency banknote,a value of the currency banknote indicating the payment amount.
 28. Thecomputer-implemented method of claim 23, wherein: in response toreceiving the payment transaction information from the one or morecomputing devices, the payment processing system transfers the paymentamount from the sender payment account to the recipient payment account.29. The computer-implemented method of claim 23, further comprising:determining social networking payments are enabled in an accountassociated with the recipient and electronic payment account informationassociated with the recipient is registered by the recipient on therecipient social network identity page; wherein the recipient socialnetwork identity page is provided for display in the social networkingapplication on the sender remote computing device in response todetermining that social networking payments are enabled and electronicpayment account information is registered.
 30. The computer-implementedmethod of claim 23, further comprising: in response to receiving thepayment transaction information from the sender remote computing device,providing a payment confirmation interface object to a recipient remoteclient device associated with the recipient social network identitypage, the payment confirmation interface object comprising a senderidentifier, the payment amount, and a request for a payment acceptancefrom the recipient; and receiving an acceptance notification from therecipient remote computing device, wherein communicating the paymenttransaction information to the payment processing system is onlycompleted if the acceptance notification is received from the recipient.31. The computer-implemented method of claim 23, further comprising:receiving a payment confirmation from the payment processing system andposting the payment confirmation on the recipient social networkidentity page.
 32. A computing system, comprising: one or moreprocessors; and one or non-transitory computer readable media thatcollectively store instructions that when executed by the one or moreprocessors cause the one or more processors to perform operations, theoperations comprising: providing for display, a recipient social networkidentity page in a social networking application on a sender remotecomputing device, the recipient social network identity page including apayment object interface; detecting selection of the payment objectinterface indicating that a user associated with the sender remotecomputing device intends to send a payment to a recipient associatedwith the recipient social network identity page; in response to thedetecting, providing for display, a payment information object on thedisplayed recipient social network identity page, the paymentinformation object enabling receipt of payment transaction informationby the one or more computing devices via the sender remote computingdevice; receiving the payment transaction information from the senderremote computing device; and communicating to a payment processingsystem the received payment transaction information and an instructionto settle a payment amount from a sender payment account associated withthe user to a recipient payment account associated with the recipient.33. The computing system of claim 32, wherein: the payment objectinterface includes one or more fields to receive an input of the paymenttransaction information.
 34. The computing system of claim 33, wherein:the one or more fields are pre-populated with at least a portion of thepayment transaction information.
 35. The computing system of claim 32,wherein: the payment transaction information comprises at least a senderpayment account identifier associated with a sender payment account andthe payment amount.
 36. The computing system of claim 32, wherein: inresponse to receiving the payment transaction information from the oneor more computing devices, the payment processing system transfers thepayment amount from the sender payment account to the recipient paymentaccount.
 37. The computing system of claim 32, further comprising:determining social networking payments are enabled in an accountassociated with the recipient and electronic payment account informationassociated with the recipient is registered by the recipient on therecipient social network identity page; wherein the recipient socialnetwork identity page is provided for display in the social networkingapplication on the sender remote computing device in response todetermining that social networking payments are enabled and electronicpayment account information is registered.
 38. One or morenon-transitory computer readable media that collectively storeinstructions that when executed by one or more processors cause the oneor more processors to perform operations, the operations comprising:providing for display, a recipient social network identity page in asocial networking application on a sender remote computing device, therecipient social network identity page including a payment objectinterface; detecting selection of the payment object interfaceindicating that a user associated with the sender remote computingdevice intends to send a payment to a recipient associated with therecipient social network identity page; in response to the detecting,providing for display, a payment information object on the displayedrecipient social network identity page, the payment information objectenabling receipt of payment transaction information by the one or morecomputing devices via the sender remote computing device; receiving thepayment transaction information from the sender remote computing device;and communicating to a payment processing system the received paymenttransaction information and an instruction to settle a payment amountfrom a sender payment account associated with the user to a recipientpayment account associated with the recipient.
 39. The one or morenon-transitory computer readable media of claim 38, wherein: the paymentobject interface includes one or more fields to receive an input of thepayment transaction information.
 40. The one or more non-transitorycomputer readable media of claim 38, wherein: the payment transactioninformation comprises at least a sender payment account identifierassociated with a sender payment account and the payment amount.
 41. Theone or more non-transitory computer readable media of claim 38, wherein:in response to receiving the payment transaction information from theone or more computing devices, the payment processing system transfersthe payment amount from the sender payment account to the recipientpayment account.
 42. The one or more non-transitory computer readablemedia of claim 38, further comprising: determining social networkingpayments are enabled in an account associated with the recipient andelectronic payment account information associated with the recipient isregistered by the recipient on the recipient social network identitypage; wherein the recipient social network identity page is provided fordisplay in the social networking application on the sender remotecomputing device in response to determining that social networkingpayments are enabled and electronic payment account information isregistered.